注意别踩坑！PG大表又发现一处隐患

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

第31期吐槽:PG 不支持分区索引，给大表埋下巨大隐患

1、产品的问题点

• PG 不支持分区索引

• 之前写过一篇单表不要超过8.9亿。

  《什么？PG单表别超过8.9亿条记录? 》虽然17解决了那个问题，今天我要再放一个理由，总之PG大表支持就是差点意思。

2、问题点背后涉及的技术原理

• PG的索引支持到表级别, 如果是分区表那么每个分区创建对应索引, 索引不能单独进行分区. 例如一个100亿条记录的单表, 如果要创建索引只能创建普通索引, 索引本身不能分区.

• 或者如果这是个分区表，PG只能创建每个分区的本地索引，不能创建分区表索引分区的统一全局索引并对索引任意选择列进行分区。

3、这个问题将影响哪些行业以及业务场景

• 当单表较大时

• 当使用分区表时

4、会导致什么问题?

• 单表较大时, 索引也会非常庞大, 可能带来一些问题:

• 创建索引的耗时变长,

• 索引深度变大导致搜索路径变深, 需要访问更多的数据块才能访问到索引的leaf node, 性能下降,

• 单个索引巨大，无法并行回收垃圾，垃圾回收时间变长, 更容易引发数据膨胀, 性能逐渐降低.

• 如果系统中有多个块设备、多个表空间, 由于1个索引只能存放在1个表空间内, 那么将无法很好的利用多个块设备的性能.

5、业务上应该如何避免这个坑

• 避免单表(或单一分区)的数据量过大, 例如不超过8.9亿条记录(经验). 超过后建议分区.

• 如果更新频率巨大, 例如建议单个分区不超过1亿条(经验)

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理成本增加

7、数据库未来产品迭代如何修复这个坑

• 内核层面支持分区索引, 如果是分区表则可以支持指定其他索引分区键.

• 根据某些表达式、字段HASH、范围进行索引分区

• 每个索引分区可以指定不同的表空间.

• 每个索引分区可以并行进行垃圾回收

本期彩蛋-推荐一个公众号

这是一个国产数据库-非专业技术人的公众号
平时发一些粗浅的技术概念、招投标信息和职场杂谈。
如果技术搞累了，可以关注、轻松一下！

文章中的参考文档请点击阅读原文获得. 

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: